Internet Accounting

This article provides an introduction to Internet accounting and discusses the status of related work within the IETF and IRTF, as well as certain research projects. Internet accounting is different from accounting in POTS. To understand Internet accounting, it is important to answer questions like "what is being paid for" and "who is being paid". With respect to the question "what is being paid for" a distinction can be made between transport accounting and content accounting. Transport accounting is interesting since techniques like DiffServ enable the provision of different quality of service classes; each class will be charged differently to avoid all users selecting the same top-level class. The interest in content accounting finds its roots in the fast growth of commercial offerings over the Internet; examples of such offerings include remote video and software distribution. The question "who is being paid" has two possible answers: the network provider or the owner of the content. The case in which the network provider issues the bill is called provider-based accounting. Since this case will become more and more important, this article introduces a new architecture for provider-based accounting

Management of networks that provide QoS guarantees

This paper presents the results of a case study to the feasibility of introducing ATM SVCs into the Dutch SURFnet research ATM network. The key issue that is examined are the implications of the Quality of Service support of ATM. QoS guarantees for a connection require a portion of the finite ATM network resource. Once all network resource is allocated to connections no new connections will be accepted, and users will start experiencing denial of service. The key research question here is if and how this denial of service probability can be kept to a minimum

Initial service management architecture

This document describes D2.2 of the Internet Next Generation project. Internet Next Generation is a project performed within the context of the Gigaport programme, and is funded by many organizations within the Netherlands. The architecture that is described within this document explains how customers of a Differentiated Services (DiffServ) network can manage the service that is provided by them, by reading and modifying QoS parameters in an interactive way. Which parameters are available and which values these parameters can take, is defined in the Service Level Specification (SLS), which is part of the Service Level Agreement (SLA). The form of management in which customers can modify the behaviour of the provided service is called Customer Service Management (CSM); the idea that customers can manage the behaviour of the provided service is not only interesting in case of DiffServ, but also in cases like Mobile IP, IP security or Virtual Private Networks (VPNs). The scope of this deliverable is restricted to QoS management in a DiffServ environment; a subsequent deliverable will extend this work and address how service .management can be performed in other environments, like IntServ / RSVP. This new deliverable will also address the problem of inter domain management

Service Level Agreements : Internet NG Deliverable D2.7

Internet is currently evolving from a best effort only service towards a service that supports different levels of Quality of Service (QoS). The service provider makes a (legally binding) commitment to deliver those specified levels of QoS. The next step is to enable customers to influence the behavior and configuration of their own instance of the service. This is called Customer Service Management. A key concept to enable customer service management is the concept of a Service Level Agreement. In this deliverable Service Level Agreements (SLAs) are defined and examined in detail, in particular for IP based networks like the Internet

Bulk transfers of MIB data

Since the original days of SNMP back in early 1988, the requirements for managing IP-based networks like the Internet have changed considerably. An important change is that the total amount of management information that needs to be transferred has increased greatly. Not only did the size of traditional MIB data grow, for example IP routing tables and TCP connection tables, but also new types of management information appeared, for instance accounting tables, which tend to be bulky. The widely deployed SNMP version 1 was not designed for transferring large amounts of data. The overall latency of such transfers can be quite high and the way in which the SNMP messages are encoded for transmission over the network is not particularly efficient. The new version 3 of the SNMP protocol, while improving on other issues like security and access control, does not improve the transfer of large amounts of MIB data sufficiently, even though it provides a get-bulk operation. In this article, we look into ways of making bulk transfers of MIB data between SNMP agents and managers more efficient. We consider a bulk transfer to be the transfer of several hundreds of kilobytes of MIB data in a single logical transaction